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(54) A method and system for loading classes in read-only memory 



(57) A method and system for providing an execut- 
able module having an address space for storing pro- 
gram data that is to reside in a read-only storage medi- 
um and an address space for storing program data that 
is to reside in a random access memory is herein de- 
scribed. The executable module represents Java class- 
es that are structured for dynamic class loading. A static 
class loader is used to modify the class structure to ac- 
commodate static loading. The static class loader also 
identifies methods that contain unresolved symbolic ref- 



erences and data that varies during the execution of the 
module. These methods and data are identified in order 
to place them in the address space that resides in the 
random access memory. The static loader is beneficial 
in a distributed computing environment having a client 
computer that has little or no secondary storage thereby 
requiring applications to run entirely in random access 
memory. By lutilizing a read-only memory to store stat- 
ically loadable classes, the random access memory is 
left available for other uses. 
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Description 

The present invention relates generally to object- 
oriented computer systems having classes that are dy- 
namically loaded at runtime, and particularly to a system 
and method for preloading a subset of the classes in a 
read-only memory. 

BACKGROUND OF THE INVENTION 

A current trend in object-oriented programming lan- 
guages is to extend the functionality of the language to 
accommodate the distribution of dynamic content in a 
distributed computing environment In one such lan- 
guage, this is accomplished by dynamically loading 
classes at runtime. A class is a collection of variables 
and methods that model the behavior of an object By 
dynamically loading classes at runtime, existing appli- 
cations can add functionality by linking in new classes 
that reside on any computer system within the distribut- 
ed computing environment. 

In such languages, symbolic references are used 
to refer to the class members (i.e., the class 1 methods 
and variables). When a class is invoked, the dynamic 
loader determines the storage schema for the class and 
resolves the symbolic reference. Such a loading 
scheme is beneficial when accessing classes that are 
updated often. However, a limitation of such a loading 
scheme is its dependency on a read/write memory de- 
vice such as a random access memory (RAM). In a com- 
puting environment that has little or no secondary stor- 
age (e.g., non-volatile magnetic disk storage), dynamic 
loading of the classes in this manner can quickly use up 
the storage capacity of the RAM. As the capacity of the 
RAM is limited, it is desirable to minimize the amount of 
RAM that is used by an application. Accordingly, there 
exists a need to limit the amount of RAM that is utilized 
toexecute object-oriented program code having dynam- 
ically loadable classes. 

- it would be beneficial to provide a method and sys- 
tem which overcomes the deficiencies of the prior art 

SUMMARY OF THE INVENTION 

In summary, this disclosure pertains to an offline 
class loader that is used to produce an executable mod- 
ule whose classes are preloaded into memory without 
requiring runtime dynamic loading. The executable 
module, nevertheless, contains a class structure that is 
tailored for runtime dynamic loading. Thus, the offline 
class loader modifies the existing class structures to ac- 
commodate static loading. However, the class structure 
allows for varying data and methods that contain unre- 
solved references. The offline class loader tags these 
methods and data specifying that they are to be stored 
in a random access memory. All other data is stored in 
a read-only memory. At the completion of the static load- 
ing process, a preloadable executable module is gener- 



ated that contains two addresses spaces. A first address 
space that contains methods having unresolved refer- 
ences and data that varies during the execution of the 
module is loaded in a random access memory. The sec- 

5 ond address space contains methods having static load- 
ed classes and constant data which is loaded into a 
read-only memory. 

A preloadable executable module of this fashion is 
advantageous in a distributed computer system having 

10 client computers with little or no secondary storage. 
Such client computers require applications to run entire- 
ly in random access memory which quickly turns into a 
limited resource. By utilizing the offline class loader to 
partition an application into two address spaces, the 

is amount of RAM utilized by the preloadable module is 
minimized. 

In an embodiment, a client computer having mini- 
mal secondary storage utilizes an offline class loader to 
preload a browser in the client's read-only memory. The 

20 browser is partitioned into the aforementioned two ad- 
dress spaces. At system initialization or power up, the 
random access memory portion of the browser is loaded 
from read-only memory into the random access memo- 
ry. By executing a large portion of the browser from read- 

2S only memory, the browser has additional RAM storage 
to store information-content and executable modules 
that it can obtain from other server computers that the 
client is in communication with. 

30 BRIEF DESCRIPTION OF THE DRAWINGS 

Examples of the invention will be described in con- 
junction with the drawings, in which: 

Fig. 1 is a block diagram of a distributed computer 
35 system. - 

Fig. 2 is a block diagram of a client computer in the 
distributed computer system of Fig. 1 . 

Fig. 3 is a flow diagram illustrating the processing 
components used to produce the preloadable executa- 
40 ble module. 

Fig. 4 illustrates the file layout for a class file. 

Fig. 5 illustrates the file layout for a constant pool. 

Fig. 6 illustrates the class block data structures. 

Fig. 7 illustrates an instruction bytecode stream. 
45 Fig. 8 is a flow chart of the method used by the of- 
fline class loader. 

Fig. 9 is a flow chart of the method for building the 
class block data structures. 

Fig. 10 is a flow chart of the method for eliminating 
so duplicate constants. 

Fig. 11 is a flow chart of the method for converting 
a non-quick instruction format into a quick instruction 
format. 

Fig. 12 is a block diagram showing the mapping of 
55 a preloaded application into read-only memory and ran- 
dom-access memory and indicating the loading of the 
portion of the methods and data mapped into random- 
access memory by a static class initializer. 
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DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

The method and system described herein utilizes a 
distributed computing environment having a communi- 5 
cation link that connects at least one server computer 
and a number of client computers. Some of the client 
computers have little or no secondary storage (e.g., 
non-volatile magnetic disk storage) thereby requiring 
applications to be run entirely from random access 10 
memory. An application developed in the Java program- 
ming language is executed on such a client computer 
Preferably, the application is a browser that is used to 
import Java content, such as Java applets, from one or 
more server computers. Typically, the browser is an in- is 
terpreted program module that retrieves Web docu- 
ments utilizing a HyperText Transfer Protocol (HTTP) to 
access one or more Web pages formatted as HyperText 
Markup Language (HTML) documents from a server 
acting as a Web site. The HTML documents are inter- 20 
preted and presented to the user associated with the 
client computer. Often, the. HTML documents embed ap- 
plets. An applet is a executable module represented as 
a Java class. The browser loads in the applet and its 
associated classes in order to execute the applet. 25 

The browser, the HMTL documents, and the applets 
all reside in the computer's RAM. On occasion, the 
amount of data that is loaded into RAM may exceed its 
capacity. As the client computer may have no secondary 
storage, it is advantageous to place portions of the 30 
browser and other basic support classes in a read-only 
^memory. In this manner. RAM storage is preserved par- 
ticularly for the imported applets. Preferably, the brows- 
er and other basic support classes (e.g., I/O and utility 
classes) are preloaded in a read-only memory. 35 

The offline class loader partitions a Java applica- 
tion, such as the browser and the basic support classes, 
into at least two separate address spaces. A first ad- 
dress space resides in a read-only memory device and 
contains methods that do not require dynamic loading 40 
and data that remains constant. The second address 
space resides in a read/write memory device, such as 
random access memory, and contains methods that re- 
quire dynamic loading and data that is varied during ex- 
ecution. 45 

A browser partitioned in this manner can be initially 
stored in the read-only memory of the client computer. 
When the system powers on, the second address space 
is preloaded into the RAM. This will leave a large amount 
of RAM storage for use by the browser to import HTML so 
documents, applets, other information-context, and ex- 
ecutable modules that are accessible through the com- 
munications link. 

It should be noted that this disclosure is described 
with reference to the Java programming language. For ss 
this reason, this description will utilize the nomenclature 
of Java. The following Java nomenclature is used fre- 
quently throughout the description and will be described 



herein briefly. A class is a grouping of instance variables 
and methods that is used to describe the behavior of an 
object. An object is an instance of a class. An instance 
variable is the data of an object that is instantiated from 
a class. A static instance variable is one that will be the 
same for all instances of the class. A non-static instance 
variable varies for each instance of the class. Constant 
data refers to data that is not altered during program 
execution. 

A method is a program segment that performs a 
well-defined series of operations. In Java, a method is 
implemented by instructions represented as a stream of 
bytecodes. A bytecode is an 8-bit code that can be a 
portion of an instruction such as an 8-bit operand or op- 
code. An interface is an abstract class where the byte- 
codes that implement the method are defined at runt- 
ime. A Java application is an executable module con- 
sisting of bytecodes that can be executed using the Java 
interpreter or the Java just-in-time compiler. A more de- 
tailed description of the features of the Java program- 
ming language is described in Tim Rrtchey, Program- 
ming with Java Beta 20. New Riders Publishing (1995). 

Referring to Fig. 1 , there is shown a distributed com- 
puter system 100 having multiple client computers 102 
and multiple server computers 104. In an embodiment, 
each client computer 102 is connected to the servers 
104 via the Internet 106, although other types of com- 
munication connections could be used. Preferably, the 
server and client computers can be desktop computers, 
such as Sun workstations, IBM compatible computers 
and Macintosh computers, however, virtually any type 
of computer can be a server or client computer. Further- 
more, the system is not limited to a distributed computer 
system. It may be practiced without the specific details 
and may be implemented in various computer systems 
and in various configurations, or makes or models of 
tightly-coupled processors or in various configurations 
of loosely-coupled microprocessor systems. 

In an embodiment, one or more server computers 
act as Web sites containing a repository of HTML doc- 
uments containing Java content or applets. The client 
computer executes a browser that provides a user as- 
sociated with the client computer with access to the 
HTML documents available from the server computer. 
Referring to Fig. 1 , a server computer typically includes 
one or more processors 112, a communications inter- 
face 116, a user interface 114, and memory 110. Mem- 
ory 110 stores: 

• an operating system 1 18; 

• an Internet communications manager program or 
other type of network access procedures 120; 

• a compiler 122 for translating source code written 
in the Java programming language into a stream of 
bytecodes; 

• a source code repository 1 24 including one or more 
source code files 126 containing Java source code; 

• a class file repository 128 including one or more 
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class files 1 30, and one or more class libraries 1 31 
containing class files, each class file containing the 
data representing a particular class; 

• an offline class loader 1 32 which is used to preload 
a certain set of classes; the offline class loader can 
also be referred to as a static class loader, 

• an assembler 1 34 which produces an object file rep- 
resenting the class members, class data structures, 
and memory storage indicators in a format that is 
recognizable for the linker; 

• a linker 136 for determining the memory layout for 
a set of preloaded classes and for resolving all sym- 
bolic references; 

• a browser 138 for use in accessing HTML docu- 
ments; and 

• one or more data files 146 for use by the server. 
The browser can include: 

• a runtime time class loader module 140, which 
loads classes into a users address space and uti- 
lizes the bytecode program verifier to verify the in- 
tegrity of the methods associated with each loaded 
class; 

• a bytecode program verifier module 142 for verify- 
ing whether or not a specified program satisfies cer- 
tain predefined integrity criteria; and 

• a HTML loader 1 44 for loading HTML documents; 

as well as other modules. 

Fig. 2 illustrates the client computer that includes 
one or more processors 202, a communications inter- 
face 206, a user interface 204, a read-only memory 208 
and a random access memory 210. The read-only mem- 
ory 208 stores a portion of the browser 21 2 and support 
procedures (including an operating system 213 and net- 
work access procedures 214) that contain methods hav- 
ing no unresolved references and data that remains 
constant. 

The random access memory 210 stores: 

• a second portion of the browser 215 and support 
procedures 216, 217 that contains methods having 
unresolved references and data that is altered dur- 
ing the application's execution; 

• a HTML document repository 220 containing one or 
more HTML documents 222 obtained by the brows- 
er at the request of the user through the user inter- 
face 204; 

• a class file repository 224 containing one or more 
class files or applets 226; and 

• one or more data files 228 that the client may utilize 
during its processing. 

Fig. 3 is an overview illustrating the sequence of 
steps used to produce a pre loadable executable mod- 
ule. It should be noted that the method and system de- 
scribed herein pertains to preloading the browser and 



other support procedures. However, the method and 
system described herein is not limited to these particular 
Java applications. Any Java application, or any other set 
of methods that are normally linked at run time could be 
s preloaded using the method and system described 
herein. 

The source code 126 for each class that comprises 
the Java application is compiled by compiler 122 into a 
class file 130. The class file contains class data struc- 
io tures representing the classes, each method's byte- 
codes, constant data, as well as other information. A 
more detailed description of the class file is provided be- 
low. Alternatively, the class files corresponding to the 
application can already reside in one or more class li- 
1* braries 1 31 . Once the class files are available, the entire 
set of class files 1 28 that constitute an application to be 
preloaded are transmitted to the offline class loader 1 32. 

The goal of the offline class loader 132 is to deter- 
mine which methods and variables associated with each 
20 class can be stored in a read-only memory and which 
must be stored in a random access memory device. 
Methods that invoke Java interfaces or utilize non-static 
instance variables need to reside in random access 
memory. This is because the bytecodes that implement 
25 interfaces are determined at runtime and non-static in- 
stance variables are altered for each instantiation of the 
associated class. The offline class loader 132 finds 
these methods and variables and flags them by inserting 
a special indicator that specifies that they are to be load- 
30 ed in a random access memory device. The offline class 
loader also performs a number of optimizations in order 
to produce a more compact representation of the exe- 
cutable code. For example, the constant pool that is as- 
sociated with each class is combined for ail the classes 
35 residing in the application. In addition, the offline class 
loader performs additional processing to tailor the class 
files that were originally structured for dynamic loading 
for a preloaded class environment. 

The output of the offline class loader 302 can con- 
40 sist of two files: a constant pool file containing the con- 
stant data for the entire application; and an updated 
class file containing the class data structures and class 
members. The data in both of these files is formatted as 
data definitions, where each definition specifies a byte- 
45 code and an offset indicating a memory location. The 
updated class file will include the memory storage indi- 
cators which will indicate in which type of memory stor- 
age device a particular set of bytecodes is to reside. 
However, the method and system described herein is 
50 not limited to producing these two files. Other file con- 
figuration can be used including, but not limited to, a sin- 
gle file containing all the related class data. 

The files are then transmitted to an assembler 1 34 
which produces an object module having the required 
55 format for the linker to map the data into the appropriate 
address spaces. Preferably, there will be two address 
spaces, one for a random access memory device and a 
second for read-only memory device. The object mod- 
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ule is then transmitted to the linker 1 36 which generates 
a memory layout lor the classes in the application. Once 
the memory layout is determined, the linker 136 re- 
solves all symbolic references and replaces them with 
direct addresses. The memory layout is partitioned into 
the two addresses spaces. The methods and data that 
were flagged for read-only memory are included in the 
first address space and the methods and data that were 
flagged as requiring storage in a random access mem- 
ory are included in a second address space. The output 
from the linker 1 36 is a preloadable executable module 
306 containing the methods and data for these two ad- 
dress spaces. 

The main function of the offline class loader as not- 
ed above is to determine the methods and data that are 
to be stored in a read-only memory and those that are 
to be stored in a random access memory. In addition, 
the constant pool for all the preloaded classes are pref- 
erably combined by the offline class loader, thereby min- 
imizing the amount of read-only storage utilized. In order 
to combine the constant pools, certain optimizations are 
performed to reduce the amount of storage that is used. 
Specifically, duplicate expressions are eliminated and 
strings that are part of longer strings are replaced with 
pointers to the appropriate substring positions in the 
longer string. 

The universal constant pool, containing all the 
classes, is partitioned into two segments, the first seg- 
ment spanning 256 bytes and the second segment 
spanning 64k minus 256 bytes. The first segment can 
contain at most 256 constants and the second segment 
contains the remaining constants. The constant pool is 
ordered such that the most frequently referenced con- 
stants are stored in the first segment of the pool and the 
least frequently referenced constants are stored in the 
second segment. Once the constant pool is combined, 
bytecodes that reference the constants may need to be 
adjusted. Constants in the first segment are referenced 
by an 8-bit operand whereas constants in the second 
segment are referenced by two 8-bit operands (see Fig. 
7 where operand 702 is an 8-bit operand and operands 
704 and 706 together form a 16-bit operand). The ex- 
pansion from an 6-bit operand to a 16-bit operand re- 
quires adjusting those bytecodes that reference con- 
stants in the second segment of the universal constant 
pool, as well as adjustment of bytecode offset values (e. 
g., in branch instructions) in the methods to account for 
the changed relative positions of the bytecodes in those 
methods. In addition, the alteration of the bytecodes re- 
quires updating the offsets stored in the exception table 
to reflect the changed bytecode start and end positions 
within the methods to which various exception handlers 
are assigned. 

Further, the offline class bader performs two other 
transformations in order to tailor the class structure to 
one suited for preloading classes. A static class initial- 
izer is created, which performs class initialization for the 
classes that are preloaded. Also bytecodes using a non- 



quick instruction format that symbolically reference 
methods are receded in a quick instruction format that 
references the methods directly. 

Fig. 8 illustrates in further detail the steps. used by 
s the offline class loader 132. Initially the offline class 
loader receives a class file for each class that is part of 
the application whose classes are to be preloaded. Fig. 
4 illustrates a format for the class file. The class file con- 
tains one or more header records 402, a constant pool 
10 404, one or more methods 406, and an exception table 
408. The header records 402 can indicate the size of 
the constant pool, the number of methods, and the size 
of the exception table. The constant pool 404 includes 
data that remains unaltered during the execution of the 
is application. Examples of such data can include string 
constants, static final integers, references to methods, 
references to classes, and references to interfaces. The 
method data 406 consists of a stream of bytecodes that 
implement each method. Each entry in the exception ta- 
20 ble gives a start and end offset into the bytecodes, an 
exception type, and the offset of a handler for the ex- 
ception. The entry indicates that when an exception of 
the indicated type occurs within the code indicated by 
the starting and ending offsets, a handler for the excep- 
ts tion will be found at the given handler offset. 

Each class file is read by the offline class loader 
(step 802) and the appropriate class data structures for 
each class are built (step 804), that is stored in the mem- 
ory of the computer being used to preprocess the appli- 
30 cation. Fig. 6 illustrates the class data structures 600. 
For each class there is a class block 602, one or more 
method blocks 604, bytecodes for each method 608, 
one or more field blocks 614, separate data areas for 
the fields 618, a constant pool 624, a map table 626 and 
35 an exception table 628. 

The class block is a fixed-size data structure that 
can include the following data: 



40 



45 



the class name 630; 

a pointer 632 to the class block of the current class' 
immediate superclass; 

an array of one or more pointers 634, each pointer 

referencing a method block; 

an array of one or more pointers 636, each pointer 

referencing a field block; 

a pointer 638 to the class 1 constant pool; and 

a pointer 640 to the class* exception table. 



A method block 604 is a fixed-sized data structure 
so that contains a predetermined number of methods. One 
or more method blocks are allocated to contain ail the 
methods of a class. A method block 604 contains the 
method's name 612 and a pointer 610 to the corre- 
sponding bytecodes 608. 
55 A field block 614 is a fixed-size data structure that 
contains instance variables or fields. There is a different 
field block format for each of the two different types of 
instance variables provided in Java. The first format 616 
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is used for integer or floating point instance variables. 
This format 616 contains the name of the instance var- 
iable, the type (e.g. integer or floating point), and its val- 
ue. The second format 620 is used for double or long 
type instance variables. This format 620 contains the 
name of the instance variable, the type (e.g., double or 
long) and a pointer to location of the value of the in- 
stance variable 618. 

Fig. 9 illustrates the steps used to build the class 
data structures. The information in the header record is 
used to allocate space for each of the class data struc- 
tures (step 1002). Once the class data structures are 
allocated, pointers to the location of each of these struc- 
tures is included in the class block (step 1004). 

Next, the offline class loader reads in the constant 
pool. Prior to discussing these steps, the content of the 
constant pool will be described first. Fig. 5 illustrates the 
structure of the constant pool that is stored in each class 
file. A first entry contains the name of the class and the 
name of the superclass 502. These names are stored 
as string constants and the first entry contains pointers 
to the locations of these strings in the constant pool. The 
next entry pertains to the fields or instance variables. A 
header 504 is used to denote the number of fields in the 
constant pool. The various fields 506 follow the header. 

Likewise, the string constants are preceded by a 
header 508 that indicates the number of string constants 
in the constant pool. The various string constants 510 
follow. String constants are used to denote method 
names, class names, and interface names. Next, the 
method references are stored in the constant pool pre- 
ceded by a header indicating the number of methods 
512. The constant pool contains for each method a 
method pointer 51 1 that contains a pointer to the meth- 
od's name 51 4 and the method's class name 51 6. These 
names are stored as string constants in the constant 
pool. The method pointer 511 is used to symbolically ref- 
erence a method. This is used in the non-quick format 
of an invoke method instruction. 

A method can contain an instruction to invoke a 
method. The instruction in the non-quick format can be 
as follows: 

invoke method "class". "method" (1) 

where "class" refers to the string constant containing the 
class name and "method" refers to the string constant 
containing the method name. The invoke method in- 
struction contains a pointer to the method's pointer 511 . 
The offline class loader attempts to resolve this symbolic 
reference by adding to the method's name a pointer to 
the method's block. Once the linker has determined the 
memory layout for the classes, the linker replaces the 
non-quick format of the invoke method instruction by the 
quick format which directly references the method (i.e., 
by storing the method's address) By resolving the sym- 
bolic reference, the method can be preloaded. 



Referring back to Fig. 9, storage is allocated for a 
map table 626 that will track the movement of the con- 
stants from their original location in the class file's con- 
stant pool to various temporary locations until the con- 

s stants are stored in the universal constant pool. A map 
table 626 is created for each class and maps the original 
address of each constant in the constant pool to its cur- 
rent location (step 1006). All data contained in the con- 
stant pool except for the fields are read from the class 

io file and stored in the constant pool (step 1 008). As con- 
stants are transferred from the class file to the constant 
pool, the map table 626 is updated to reflect the original 
address and the current location in the constant pool 
(step 1008). However, the fields that are read from the 

is constant pool are loaded into one or more field blocks 
and no entries are made for them in the map table (step 
1008). 

The method data is read from the class file and 
stored in one or more method blocks. Additional storage 

20 is allocated for the bytecodes associated with each 
method. The method's name is placed in the method 
block along with a pointer to the location of the byte- 
codes (step 1010). Likewise, the exception table is load- 
ed from the class file into its corresponding exception 

25 table data structure (step 101 2). 

Referring back to Fig. 8, after the class data struc- 
tures have been built, a hash table 180 (see Fig. 3) is 
allocated in accordance with the total size of all the con- 
stant pools and is used later in the elimination of dupli- 

30 cate constants (step 805). 

Next, the offline class loader proceeds to eliminate 
duplicate constants. This is performed in order to com- 
bine the constant pools of all the classes in a space ef- 
ficient manner. For each class file (step 806), each entry 

35 in the class' constant pool is scanned for duplicate con- 
stants (step 812). Referring to Fig. 10, duplicate con- 
stants are detected by using a hash table. The hash val- 
ue of the constant is determined by an appropriate hash- 
ing function (step 1102). A check is made to determine 

40 whether the hash value is contained in the hash table 
(step 1104). If the hash value exists in the hash table, 
then the constant is a duplicate and the entry is deleted 
from the constant pool by altering the constant's entry 
in the map table to reflect the memory location of the 

45 existing constant (step 1 1 06). Otherwise, the constant's 
hash value and memory location are stored in the hash 
table (step 1108). 

Referring back to Fig. 8, the offline class loader pro- 
ceeds to determine common substrings. A common 

so substring is one that is contained as part of a longer 
string already stored in the constant pool. For each class 
file (step 814) each string constant is scanned to deter- 
mine whether it is part of a larger string contained in the 
constant pool (step 816). This can be accomplished us- 
55 ing one of several well-known string matching algo- 
rithms. 

When such a substring is found, it is replaced with 
a pointer to the position of the substring in the larger 
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string (step 818). 

Next the offline class loader proceeds to scan the 
bytecodes of all the methods contained in each of the 
class files (steps 820-824). Referring to Fig. 11 , the byte- 
codes are inspected for an invoke interface instruction 
(step 1202). A method having an invoke interface in- 
struction is marked for RAM storage since the method 
being invoked by such an instruction will not be imple- 
mented until runtime (step 1 204). Otherwise the byte- 
code is inspected for an invoke method instruction (step 
1206). In this situation, a pointer 518 (see Fig. 5) to the 
method block containing the method to be invoked is 
added to the method's name, that is stored in the con- 
stant pool (step 1208). Later when the linker has deter- 
mined the memory layout of all the classes, the linker 
replaces the symbolic reference to the method with the 
direct address to the method. This is determined by trac- 
ing the method's name pointer to the method block that 
contains a pointer to the method. 

As each bytecode is scanned, a reference count is 
made to each constant that is accessed by the bytecode 
(step 828). The reference count is an extra field that is 
contained in the map table. This will be used later to 
determine the most frequently used constants in order 
to reorder the constant pool. In addition, each bytecode 
is scanned for fields that are altered by the bytecode. 
This can be determined by checking if the field is ever 
used on the left hand side of an assignment statement. 
In this case, the field accepts a new value. If the altered 
field is one that has its value stored in the field block, 
than the entire field block is marked for RAM storage 
(step 830). 

Once space is allocated for the universal constant 
pool, each entry from the various class constant pools 
is merged into the universal constant pool (step 902). 
As mentioned previously, the constant pool is parti- 
tioned into two segments. The first segment contains up 
to 256 of the most frequently referenced constants. The 
second segment contains the remaining constants. 
Constants that are never referenced are eliminated and 
not stored in the universal constant pool. The constant 
pool entries are read from each class* map table since 
the map table has the reference count, has eliminated 
duplicate entries, and has pointers to common sub- 
strings. 

Once the universal constant pool is formed, byte- 
codes that reference constants stored in the second 
segment of the universal constant pool require a double 
length offset value, which occupies two bytes instead of 
one, to reference the constant. This requires scanning 
through each bytecode for each class' method (steps 
906 - 908) and, for each bytecode referencing a con- 
stant in the second segment of the universal constant 
pool, replacing a one byte offset with a two byte offset 
to address the constant (step 91 0). This can be accom- 
plished by allocating another data area for storing the 
bytecodes. As the bytecodes are scanned, they are read 
into the new data area and any one byte offsets requiring 
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replacement with two byte offsets are replaced during 
this copying process. The method block is then updated 
to reflect the new storage location for the bytecodes. 
The offset operands for bytecodes representing branch- 

£ ing instructions are adjusted in accordance with the 
number of bytes (if any) added between the location of 
the branch bytecode and the branch target bytecode. 

Likewise, the exception table for each class file will 
require adjustment if any of the methods in the class file 

10 reference constants in the second segment of the con- 
stant pool. The adjusted instructions referencing con- 
stants in the second segment of the constant pool will 
occupy more space than previously, thereby affecting 
the offsets in the exception table. Revised start and end 

is offsets as well as handler offsets that are affected by the 
insertion of double length constant pool offsets are cal- 
culated and stored in the exception table (steps 
916-918). 

Next, a new method is created to handle static class 

20 initialization. Normally, when a class is dynamically 
loaded, a class initializer is run at the same time to ini- 
tialize certain variables and the like associated with the 
class. Since the classes are preloaded in the method 
and system described herein, class initialization will not 

25 bo performed. Therefore, the offline class loader has to 
create a method that will perform class initialization for 
the preloaded classes. However, a data flow analysis is 
performed first (steps 920 - 924) in order to determine 
the execution sequence for performing each class ini- 

30 tializer. The sequence is important since one class may 
utilize data that is initialized in another class. If the cor- 
rect sequence is not maintained, the static class initial- 
izer will produce incorrect results. Once the sequence 
is determined, a new method is created that will initialize 

35 each class in the sequence for those classes that are to 
be preloaded (step 926). 

The linkage indicators are then inserted into the 
class block structures in order to flag which methods and 
field blocks are to be stored in a random access mem- 

40 ory. The linker uses this information in order to create a 
separate address space for the methods and field 
blocks that are to be stored in the random access mem- 
ory. The linker can presume that the absence of an in- 
dicator indicates that the methods and fields are to be 

45 stored in read-only memory. Alternatively, an additional 
indicator can be used to explicitly indicate those meth- 
ods, class data structures, and fields that are to be 
stored in the read-only memory (step 928) 

Lastly, the offline class loader outputs the universal 

so constant pool, an updated class file containing the class 
data structures and the indicators specifying the mem- 
ory storage requirements, as well a special boot time 
initiator (step 930). 

Referring to Fig. 12, the preloadable executable 

ss module and boot time initiator 1220 are permanently 
stored in the read-only memory of a client computer. 
Each time the client computer is powered on or reboot- 
ed, the boot time initiator 1220 is automatically execut- 
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ed. Among other tasks, the boot time initiator copies all 
methods and data that must be resident in random ac- 
cess memory during execution to the random access 
memory locations assigned to them by the linker. 2. 

Although, the aforementioned system and method s 
has been described with respect to executing a Java 
browser and support procedures for use in accessing 
HTML documents through the Internet, the method and 
system described herein is applicable to any Java ap- 
plication. Moreover, the Java application need not be io 
run in a distributed environment, it can run in stand- 
alone mode executing in a client or server computer 
without importing new classes from external systems. In 
stand-alone mode, the application is partitioned into the 
two address spaces in order to satisfy the memory con- is 
straints of the particular computing environment 

Although the method and system described herein 
has been described with reference to the Java program- 
ming language it is applicable to computer systems us- 
ing other object-oriented classes that utilize dynamic 20 
runtime loading of classes. 

Further, the method and system described herein- 
above is amenable for execution on various types of ex- 
ecutable mediums other than a memory device such as 
a random access memory. Other types of executable 25 3. 
mediums can be used, such as but not limited to, a com- 
puter readable storage medium which can be any mem- 
ory device, compact disc, or floppy disk. 



Claims 

1. A method of operating a computer in a distributed 
computer system, the method comprising the steps 
of: 35 

storing in a memory a plurality of classes, each 
class including data and at least one method, 
each method including a plurality of bytecodes, 
a subset of said bytecodes including symbolic *o 
references to methods accessible by said com- 
puter; 

flagging, for each said class, said class 1 data 
when said class 1 data is modifiable by one of 
said class' methods; 46 
substituting for each said symbolic reference 
to a specified method stored in said memory, 
said specified method's memory location; 
flagging, for each said method of each said 
class, said method when one of said method's so 
bytecodes includes a symbolic reference to a 
method not stored in said memory; and 4. 
providing an executable module including each 
said class, wherein each unflagged method 
and each unflagged data is to be stored in a ss 
read-only storage medium when executing said 
executable module, and each said flagged 
method and each said flagged data is to be 



stored in a read and write-enabled storage me- 
dium when executing said executable module. 

A method for operating a computer system, said 
method comprising the steps of: 

storing in a read-only memory device a browser 
module partitioned into a first submodule and a 
second submodule, each submodule including 
a plurality of instructions and data, said second 
submodule having a subset of said instructions 
and a subset of said data, said subset of in- 
structions and subset of data including instruc- 
tions and data that are modifiable during exe- 
cution of said plurality of instructions; 
upon initiation of the computer system, storing 
the second submodule in a random access 
memory device; and 

executing the browser module to import infor- 
mation-content data and computer-executable 
modules, said imported data and said compu- 
ter-executable modules stored in said random 
access memory device. 

In a distributed data processing system having a 
plurality of computers connected by a communica- 
tions link ; one of said computers comprising: 

a memory for storing a plurality of classes, each 
said class including a plurality of data and at 
least one method, each said method including 
a plurality of bytecodes, a first set of said byte- 
codes referencing methods stored in said 
memory, a second set of said bytecodes refer- 
encing methods accessible by said communi- 
cations link; 

an offline class loader that flags, for each said 
class, said class 1 data when said class* data is 
modifiable by one of said class 1 methods, and 
that flags, for each said method of each said 
class, said method when one of said method's 
bytecodes includes a symbolic reference to a 
method not stored in said memory; and 
a linker for producing an executable module 
having a first portion and a second portion, the 
first portion including each of said class' meth- 
od and said data flagged by said offline class 
loader, and a second portion including each of 
said class' methods and said data not in said 
first portion. 

The computer of claim 3 wherein 

said first portion of said executable module is 
configured to be stored in a read and write-enabled 
medium when said executable module is executed, 
and said second portion is configured to be stored 
in a read-only storage medium when said executa- 
ble module is executed. 
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